home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / rfc / rfc1151 < prev    next >
Encoding:
Text File  |  1991-04-20  |  7.9 KB  |  227 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      C. Partridge
  8. Request for Comments: 1151                 BBN Systems and Technologies
  9. Updates: RFC 908                                              R. Hinden
  10.                                                BBN Communications Corp.
  11.                                                              April 1990
  12.  
  13.  
  14.              Version 2 of the Reliable Data Protocol (RDP)
  15.  
  16. Status of this Memo
  17.  
  18.    This RFC suggests several updates to the specification of the
  19.    Reliable Data Protocol (RDP) in RFC-908 based on experience with the
  20.    protocol.  This revised version of the protocol is experimental.
  21.  
  22.    Distribution of this memo is unlimited.
  23.  
  24. Introduction
  25.  
  26.    Experiments in 1986 and 1987 turned up some ambiguities and problems
  27.    with the RDP specification.  At the time, it was hoped that the
  28.    authors might find the time to revise the entire RDP specification to
  29.    fix these problems, however given the limited demand for RDP
  30.    implementations, the authors were never able to justify the time
  31.    involved in revising the spec.  This document lists the changes that
  32.    we believe are appropriate to make to RDP version 1.
  33.  
  34.    Readers are expected to be familiar with RFC-908.
  35.  
  36. Changes To The Protocol Header
  37.  
  38.    There are three changes to the protocol header: the checksum
  39.    algorithm has been changed, the port size increased, and the version
  40.    number incremented.  The new header format is shown in Figure 1.
  41.  
  42.    The major discovery during the testing of the protocol is that cost
  43.    of computing the the RDP checksum proved surprisingly variable; its
  44.    performance was more heavily affected by the host's data
  45.    representation than anticipated.  Optimized checksum implementations
  46.    on two comparable hardware bases gave performance that differed by a
  47.    factor of five.  Since the speed of the checksum is a key factor in
  48.    the performance of the protocol itself, this variation caused a
  49.    noticeable difference in throughput.
  50.  
  51.    The wide variation in performance on comparable machines was felt to
  52.    be undesirable, so the checksum has been changed.  RDP now uses the
  53.    16-bit TCP checksum, which is specified on page 16 of RFC-793.
  54.  
  55.  
  56.  
  57.  
  58. Partridge & Hinden                                              [Page 1]
  59.  
  60. RFC 1151                    RDP - Version 2                   April 1990
  61.  
  62.  
  63.    The 8-bit port size is probably too small to support a large range of
  64.    applications.  Accordingly, the port size is now 16-bits.  Port
  65.    numbers less than 1024 are reserved for well-defined applications.
  66.    Allocable ports begin at port number 1024.
  67.  
  68.    Finally, because the checksum and port size have been changed, the
  69.    version number has been increased to 2.
  70.  
  71.  
  72.                    0             0 0   1         1
  73.                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  74.                   +-+-+-+-+-+-+---+---------------+
  75.                   |S|A|E|R|N| |Ver|    Header     |
  76.                 0 |Y|C|A|S|U|0|No.|    Length     |
  77.                   |N|K|K|T|L| |   |               |
  78.                   +-+-+-+-+-+-+---+---------------+
  79.                 1 |         Source Port           |
  80.                   +---------------+---------------+
  81.                 2 |       Destination Port        |
  82.                   +---------------+---------------+
  83.                 3 |          Data  Length         |
  84.                   +---------------+---------------+
  85.                 4 |                               |
  86.                   +---    Sequence Number      ---+
  87.                 5 |                               |
  88.                   +---------------+---------------+
  89.                 6 |                               |
  90.                   +--- Acknowledgement Number  ---+
  91.                 7 |                               |
  92.                   +---------------+---------------+
  93.                 8 |           Checksum            |
  94.                   +---------------+---------------+
  95.                 9 |     Variable Header Area      |
  96.                   .                               .
  97.                   .                               .
  98.                   |                               |
  99.                   +---------------+---------------+
  100.  
  101.                          RDP Header Format
  102.                              Figure 1
  103.  
  104. Minor Errors and Ambiguities
  105.  
  106.    Some ambiguities and minor errors have been found in RFC-908.  They
  107.    are corrected in this section.
  108.  
  109.    The value of the state variable, SND.UNA is treated inconsistently in
  110.    the pseudo-code on pages 21-29.  On page 12, SND.UNA is defined as
  111.  
  112.  
  113.  
  114. Partridge & Hinden                                              [Page 2]
  115.  
  116. RFC 1151                    RDP - Version 2                   April 1990
  117.  
  118.  
  119.    "the sequence number of the oldest unacknowledged segment", and on
  120.    page 21 it is appropriately set to the initial sequence number when
  121.    the connection is opened.  But on page 28, when an acknowledgement is
  122.    received, SND.UNA is set to SEG.ACK, the sequence number being
  123.    acknowledged, instead of SEG.ACK+1.  A similar inconsistency occurs
  124.    on page 26.  The proper fix is to always set SND.UNA to SEG.ACK+1.
  125.  
  126.    The pseudo-code on page 25 for the SYN-SENT state is incorrect.  The
  127.    first few lines cause all packets with the ACK bit set to be
  128.    discarded, but later lines test the ACK bit.  The test for the ACK
  129.    bit should be placed after all the other tests.  Also note that if
  130.    the ACK bit is set, a RST segment is sent to reset the remote peer,
  131.    but the local peer is left half-open.  There is a similar problem in
  132.    the SYN-RCVD state.  The local peer should deallocate the connection
  133.    record and close.
  134.  
  135.    On page 24, the pseudo-code indicates that if non-data packets are
  136.    received in the CLOSED state, a RST segment with SEG.ACK set to
  137.    RCV.CUR should be sent.  RCV.CUR is not defined in the CLOSED state.
  138.    SEG.ACK should be set to SEG.SEG.
  139.  
  140.    There is some inconsistency about how to handle a RST packet in the
  141.    CLOSE-WAIT state.  On page 24, the pseudo-code shows that a RST
  142.    should cause the connection state to become CLOSED.  Text on page 13
  143.    and the state diagram on page 10 suggest the connection state should
  144.    stay in CLOSE-WAIT.  The implementation should stay in CLOSE-WAIT.
  145.  
  146.    On page 29, the pseudo-code for the OPEN state suggests that if a
  147.    data packet is received in sequence, the acknowledgement packet
  148.    should not contain EACKs.  This is misleading.  Implementations may
  149.    include EACKs in the acknowledgement.
  150.  
  151.    On page 18, it is possible to interpret the right edge as being
  152.    either inside or outside the window.  This results in a one segment
  153.    difference in the window size.  The proper interpretation is that the
  154.    right edge is outside the window.  In other words, the right edge is
  155.    the first sequence number that cannot be sent or received and the
  156.    total window size is 2*X, where X is the maximum number of
  157.    outstanding segments.
  158.  
  159.    One final problem is that RDP's flow control scheme does not allow
  160.    the receiver to close the sender's window.  As a result, if the
  161.    receiver acknowledges segments when they are received the sender can
  162.    easily send more data than the receiver is prepared to buffer.  A
  163.    solution to this problem (suggested by members of the End-2-End
  164.    Research Group) is to only acknowledge a segment after it has been
  165.    delivered to the application.  This scheme, however, has not be
  166.    tested.
  167.  
  168.  
  169.  
  170. Partridge & Hinden                                              [Page 3]
  171.  
  172. RFC 1151                    RDP - Version 2                   April 1990
  173.  
  174.  
  175. Security Considerations
  176.  
  177.    Security issues are not addressed in this memo.
  178.  
  179. Authors' Addresses
  180.  
  181.    Craig Partridge
  182.    Bolt Beranek and Newman Inc.
  183.    50 Moulton Street
  184.    Cambridge, MA 02138
  185.  
  186.    Phone: (617) 873-2459
  187.  
  188.    EMail: craig@BBN.COM
  189.  
  190.  
  191.    Robert Hinden
  192.    Bolt Beranek and Newman Inc.
  193.    50 Moulton Street
  194.    Cambridge, MA 02238
  195.  
  196.    Phone: (617) 873-3757
  197.  
  198.    Email: HINDEN@BBN.COM
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Partridge & Hinden                                              [Page 4]
  227.